1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for mapping Enterprise Java Bean™ (“EJB”) attributes to database schema.
2. Description of Related Art
Enterprise JavaBeans is a Java™ API developed by Sun Microsystems that defines a component architecture for multi-tier client/server systems. Enterprise JavaBeans define an architecture for the development and deployment of transactional, distributed object applications-based, server-side software components. These server-side components, called ‘enterprise beans,’ are distributed objects that are hosted in Enterprise JavaBean containers and provide remote services for clients distributed throughout a network. These server-side components are sometimes known as ‘Enterprise JavaBeans,’ ‘EJB components,’ ‘enterprise beans,’ ‘beans,’ and sometimes by other terms as well. In this specification, however, the server side component is generally referred to as an ‘EJB.’
EJBs are software components that run in a special environment called an EJB container. The container hosts and manages an EJB in the same manner that the Java Web Server hosts a servlet or an HTML browser hosts a Java applet. An EJB functions only in an EJB container. If an enterprise bean needs to access a JDBC connection or another enterprise bean, it does so through the container; if an enterprise bean needs to access the identity of its caller, obtain a reference to itself, or access properties it does so through the container. The enterprise bean interacts with its container through one of three mechanisms: callback methods, the EJBContext interface, or the Java Naming and Directory Interface (JNDI).
A client program contacts an EJB server and requests that the server create an EJB to do data processing on behalf of the client. The server responds by creating the server-side object (the EJB component instance that is referred to generally in this specification as an ‘EJB’). The server also returns a proxy object (the EJB object, an object that implements the EJB remote interface, referred to generally as a ‘remote object’) whose interface is the same as the EJB's and whose implementation performs remote method invocations in the EJB on behalf of the client. The client then uses the remote object as if it were a local object, never knowing or caring that a server-side EJB is actually doing all the work.
A client program creates an object on a server by use of an EJB home interface. Each EJB class has what is called a home interface that defines the methods for creating EJB instances on the server. An EJB home interface extends the interface javax.ejb.EJBHome, which defines base-level functionality for a home interface. All methods in this interface are required to be remotely executable according to Java RMI (Remote Method Invocation). The EJB home interface also defines one or more factory methods named ‘create( ).’ The return value of these factory methods is the remote interface (that is, a remote object) for the EJB.
When a client wants to create a server-side bean, an EJB, the client uses the Java Naming and Directory Interface (JNDI) to locate the home interface for the class of bean it wants. The JNDI is a standard extension to the Java core that provides a global service to any Java environment, allowing Java programs to locate and use resources by name, to find out information about those resources, and to traverse structures of resources. A client accesses JNDI services through a method name ‘lookup( )’ in an instance of JNDI's InitialContext class. This initial context lookup returns an instance of a home interface for an EJB. In this specification, such an instance of a home interface is referred to as a ‘home object.’
Once the client has the home interface for the EJB class it wants to create, it calls one of the factory methods, that is, a create( ) method, on the home interface to create a server-side object. The client-side home interface object does a remote method call to the EJB container on the server, which then creates the EJB component, that is, the EJB itself, and returns an EJB remote object to the client. The client may then call the remote object's methods, which are forwarded to the container and then to the EJB.
Container-managed persistence beans (‘CMP beans’) are the simplest for the bean developer to create and the most difficult for the EJB sever to support. CMP beans are difficult to support because all the logic for synchronizing the bean's state with its backup persistent database is handled by the container. The bean developer is required to write no data access logic, while the EJB server takes care of all persistence needs automatically, a difficult task. Many EJB containers support automatic persistence to a relational database, but the level of support varies; it is not part of any industry-wide standard or binding specification. Some EJB containers very sophisticated EJB attribute-to-database column mapping, while others are very limited.
An EJB is a complete component made up of at least two interfaces (home and remote) and a bean implementation class. Here is an explanatory pseudocode example of an EJB class:
import javax.ejb.EntityBean;public class CustomerBean implements EntityBean {intcustomerID;AddressmyAddress;NamemyName;CreditCard myCreditCard;// CREATION METHODSpublic Customer ejbCreate(Integer id) {customerID = id.intValue( );return null;}public void ejbPostCreate(Integer id) { }public Customer ejbCreate(Integer id, Name name) {myName = name;return ejbCreate(id);}public void ejbPostCreate(Integer id, Name name) { }// BUSINESS METHODSpublic Name getName( ) {return myName;}public void setName(Name name) {myName = name;}public Address getAddress( ) {return myAddress;}public void setAddress(Address address) {myAddress = address;}public CreditCard getCreditCard( ) {return myCreditCard;}public void setCreditCard(CreditCard card) {myCreditCard = card;}// CALLBACK METHODSpublic void setEntityContext(EntityContext cntx) { }public void unsetEntityContext( ) { }public void ejbLoad( ) { }public void ejbStore( ) { }public void ejbActivate( ) { }public void ejbPassivate( ) { }public void ejbRemove( ) { }}
This is an example of a CMP entity bean. Notice that there is no database access logic in the EJB. There is no database access logic in the EJB because the EJB's container provides tools for mapping the fields in the EJB ‘CustomerBean’ to a database. The CustomerBean class, for example, could be mapped to any database providing it contains data that is similar to the fields in the bean. In this case the bean's instance fields or ‘attributes’ include a primitive int and three attribute objects, Name, Address, and CreditCard. Below are exemplary definitions for the three attribute objects:
// The Name classpublic class Name implements Serializable {public String lastName,firstName, middleName;public Name(String lastName, String firstName, StringmiddleName) {this.lastName = lastName;this.firstName = firstName;this.middleName = middleName;}public Name( ) { }} // End of Name Class// The Address classpublic class Address implements Serializable {public String street,city, state, zip;public Address(String street, String city,String state, String zip) {this.street = street;this.city = city;this.state = state;this.zip = zip;}public Address( ) { }}// The CreditCard classpublic class CreditCard implements Serializable {public String number,type, name;public Date expDate;public CreditCard(Stringnumber, String type,String name,Date expDate) {this.number = number;this.type = type;this.name = name;this.expDate = expDate;}public CreditCard( ) { }}
The EJB attributes in this example are referred to as container-managed fields because the container is responsible for synchronizing their state with the database. Container-managed fields can be any primitive data types or serializable data types. This example case uses both a primitive int (customerID) and serializable objects (Address, Name, CreditCard). In order to map the dependent objects to the database a mapping tool is needed. EJB attributes that are container-managed fields must have corresponding types, that is, corresponding columns in a database table to which the EJB attributes are mapped. The CustomerBean might, for example, map to a CUSTOMER table in the database that has the following definition:
CREATE TABLE CUSTOMER{idINTEGER PRIMARY KEY,last_nameCHAR(30),first_nameCHAR(20),middle_nameCHAR(20),streetCHAR(50),cityCHAR(20),stateCHAR(2),zipCHAR(9),credit_numberCHAR(20),credit_dateDATE,credit_nameCHAR(20),credit_typeCHAR(10)}
With container-managed persistence, the EJB container needs a mapping tool that can map the bean's container-managed fields or attributes to their corresponding columns in a specific table, CUSTOMER in this example. Once the EJB's attributes are mapped to the database, and the EJB is deployed, the container will manage creating records, updating records, and deleting records in the corresponding database table in response to methods invoked on the EJB. The following exemplary XML file is an example of a conventional for mapping of EJB attributes to database columns:
<?xml version=“1.0” encoding=“UTF-8”?><map ejbattr=a1 ejb=b1 col=c1 table=t1 database=db1 schema=s1 /><map ejbattr=a2 ejb=b1 col=c1 table=t1 database=db1 schema=s1 /><map ejbattr=a1 ejb=b1 col=c2 table=t1 database=db3 schema=s2 /><map ejbattr=a1 ejb=b1 col=c3 table=t2 database=db3 schema=s2 /><map ejbattr=a2 ejb=b1 col=c3 table=t2 database=db3 schema=s2 />
This is a simple example of what is referred to in this specification as a ‘flat mapping,’ called a flat mapping because each mapping element contains references to all variable characteristics needed for mapping one EJB attribute to one database column. Readers of skill will recognize immediately that practical mappings are very voluminous, mapping many, many attributes to database columns. In addition, it is often necessary to install an EJB in more than one operating environment where more than one database schema is used for the same set of EJB attributes. That is, across multiple installations of the same EJB, the same EJB attributes are mapped to many variations of schema name, database name, table name, and column name. Modifying a mapping such as the example above requires searching through the mapping and changing each occurrence of a changed schema name, database name, table name, or column name, each of which occurs in each map entry of the structure—of which there will be many. This is a burdensome task, time consuming, and difficult to automate. For these reasons, there is a long-felt need for improved methods of mapping EJB attributes to database schema.